<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from mon.tnf on 19 December 2010 -->

<TITLE>Execution Monitoring Reference - Information</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM>
<A HREF="http://eli-project.sourceforge.net/">
<IMG SRC="gifs/elilogo.gif" BORDER=0>
</A>&nbsp;
</TD>
<TD WIDTH="25" VALIGN=BOTTOM>
<img src="gifs/empty.gif" WIDTH=25 HEIGHT=25>
</TD>
<TD ALIGN=LEFT WIDTH="475" VALIGN=BOTTOM>
<A HREF="index.html"><IMG SRC="gifs/title.png" BORDER=0></A>
</TD>
<!-- |DELETE FOR SOURCEFORGE LOGO|
<TD>
<a href="http://sourceforge.net/projects/eli-project">
<img
  src="http://sflogo.sourceforge.net/sflogo.php?group_id=70447&amp;type=13"
  width="120" height="30"
  alt="Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads"/>
</a>
</TD>
|DELETE FOR SOURCEFORGE LOGO| -->
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_1.html#SEC1">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ee.html" >Typical Eli Usage Errors</a> </td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<A HREF="mailto:eli-project-users@lists.sourceforge.net">
<IMG SRC="gifs/button_mail.gif" BORDER=0 ALIGN="left"></A>
<A HREF="index.html"><IMG SRC="gifs/home.gif" BORDER=0 ALIGN="right"></A>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>Execution Monitoring Reference</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC7" HREF="mon_toc.html#SEC7">Information</A></H1>
<P>
This chapter briefly describes the type of information that Noosa
can provide about the execution of your program and how to go 
about getting it.
<P>
<A NAME="IDX52"></A>
<A NAME="IDX53"></A>
<H2><A NAME="SEC8" HREF="mon_toc.html#SEC8">Input Text Display</A></H2>
<P>
Usually the initial input to an Eli-generated program is specified on
the command-line of the processor (see  <A HREF="clp_toc.html">Command Line Processing</A>) and subsequent input (if any) is given by the input text
itself (perhaps via <CODE>include</CODE> directives or similar mechanisms).
<P>
Noosa displays the input text as seen by your program in the top part
of the main window.
<A NAME="IDX54"></A>
(The current Noosa system does not fully support the monitoring of
programs when their input is standard input.)
The input text is shown <EM>exactly</EM> as your program sees it.  In
particular, it appears as one contiguous piece of text rather than
(say) a set of files included into other files.  Note also that when the
program stops, the input text displayed is the text that has been seen
by the program at that point.  Text encountered later on (perhaps by
later <CODE>include</CODE> directives) will be displayed when it is
encountered.
<P>
In various settings Noosa will display input text coordinates (e.g.,
when you ask to see the lexical tokens recognised).  There are two
formats used to display coordinates:
<P>
<PRE>
12,3
9,1-12,80
</PRE>
The first form indicates a single coordinate (column three of line
twelve); the second indicates a range of coordinates (column one of line
nine through to column eighty of line twelve, inclusive).
<P>
In the transcript window coordinates or coordinate ranges will be
underlined.  Clicking the left mouse button on a displayed coordinate
(or range) causes Noosa to highlight the coordinate (or range) in the
input text.  This enables you to conveniently match Noosa output to
input text.
<A NAME="IDX55"></A>
<A NAME="IDX56"></A>
<P>
As mentioned above, the input to your program may come from more than
one text file.  The coordinates used by Noosa are <EM>cumulative</EM> in
that they reflect the overall input text, not the individual text files.
To find out from which file a location comes, select the location in the
input text window and execute the Describe coord command from the
Examine menu (also available on the right button in the main windows).
<P>
<A NAME="IDX57"></A>
<A NAME="IDX58"></A>
<H2><A NAME="SEC9" HREF="mon_toc.html#SEC9">Messages</A></H2>
<P>
Eli-generated programs take text as input, analyse that text, and
perhaps produce some text as output.  During analysis, messages may be
produced for a variety of reasons.  Eli provides a module to help
generate messages (see  <A HREF="lib_1.html#SEC4">Error of Library Reference Manual</A>).
<P>
If your program generates any messages they will be displayed in the
transcript window.
The coordinate of the message will be shown with the severity and
the message text.
<P>
<A NAME="IDX59"></A>
<A NAME="IDX60"></A>
<A NAME="IDX61"></A>
<H2><A NAME="SEC10" HREF="mon_toc.html#SEC10">String Table</A></H2>
<P>
Most Eli-generated programs need to manipulate text strings.  To avoid
the overhead of copying strings around during execution, a string table
can be used.  Eli has a module that implements a string table allowing
integers to be used to represent strings (see  <A HREF="lib_1.html#SEC6">Storage of Library Reference Manual</A>).
<P>
Noosa allows you to see the contents of the string table using the
Strings command from the Examine menu.  Each string in the table will be
displayed with its index.  The String command can be used to display a
single particular string.  Select the numeric string index with the
mouse then execute String.  This mode of use is particularly useful if
the string index has already been displayed by Noosa in some other
setting (e.g., as the intrinsic attribute of a token).
<P>
<A NAME="IDX62"></A>
<A NAME="IDX63"></A>
<A NAME="IDX64"></A>
<H2><A NAME="SEC11" HREF="mon_toc.html#SEC11">Lexical Structure</A></H2>
<P>
Eli-generated programs that perform lexical analysis can do so using the
support of an automatically-generated lexical analyser
(see  <A HREF="lex_toc.html">Lexical Analysis</A>).  Noosa lets you examine the behaviour
of the generated analyser on your program's input text.
<P>
Your program will generate a stream of tokens.  Selecting an input text
coordinate (or range of coordinates) in the input text window and
executing the Token command from the Examine menu will cause Noosa to
display the tokens recognised that overlap that coordinate (or range).
<P>
The following information is displayed for each token: input text
coordinate range, numeric token code used internally by the analyser,
length in characters, the intrinsic attribute value of the token, the
input text (lexeme) matched by the token, and, for non-literal tokens,
the name of the non-literal as specified in your type-<TT>`gla'</TT>
specifications (see  <A HREF="lex_1.html#SEC1">Specifications of Lexical Analysis</A>).
<P>
<A NAME="IDX65"></A>
<A NAME="IDX66"></A>
<A NAME="IDX67"></A>
<H2><A NAME="SEC12" HREF="mon_toc.html#SEC12">Phrase Structure</A></H2>
<P>
Programs that need to determine the phrase structure of their input can
do so within Eli using automatically-generated parsers
(see  <A HREF="syntax_toc.html">Syntactic Analysis</A>).
<P>
The Noosa Phrase command (in the Examine menu) lets you look at the
phrase structure that is recognised by your parser.  Selecting an input
text coordinate in the input text window and executing Phrase will
produce a list of all the production instances recognised by your
program that overlap the selected coordinate.
<P>
The instances are listed from most general to most specific, so the
first one is always the root production of the grammar.  Each production
instance is displayed with the input text coordinate range for that
instance.  On the right-hand side of each production the symbol
corresponding to the left-hand side of the following production is
highlighted.  (Note that in some cases chain production elimination is
performed by Eli-generated parsers.  This may mean that the highlighted
symbol on the right-hand side of a production instance is not the same
symbol as the left-hand side of the next production instance.)
<A NAME="IDX68"></A>
<P>
Examination of the phrase structure with Noosa will work if you are
using either the
<A NAME="IDX69"></A>
PGS or
<A NAME="IDX70"></A>
COLA parser generating systems available within Eli
(see  <A HREF="pp_1.html#SEC8">parser of Products and Parameters Reference Manual</A>).
<P>
<A NAME="IDX71"></A>
<A NAME="IDX72"></A>
<H2><A NAME="SEC13" HREF="mon_toc.html#SEC13">Trees and Attribute Values</A></H2>
<P>
If your processor contains attribution, Eli will automatically construct
an abstract tree for the input text.  Noosa has facilities for examining
this tree and any other trees computed by your processor. 
<P>
Tree display can be enabled using the Trees item in the Windows menu.
Windows containing the selected trees will appear next time the program
is run.  There are four options in the Trees menu: Just Source, Separate
Computed, Source and Computed, and Incremental.  Any combination of
these options can be used.
<P>
The first three options draw trees in a traditional tree manner with the
root at the top and children under their parents. The Incremental option
draws the root at the left and children to the right of their parents.
The former style always uses a nice layout but always draws the whole
the tree (but see below); the latter initially just draws the root of
the tree but allows nodes to be selectively expanded (see the online
help for details).
<P>
The Just Source option causes the source tree built by your processor's
parser to be displayed.  The Separate Computed option will cause each
computed tree to be displayed in a separate window as soon as they are
complete.  This option is most suitable if you have a few largish
computed trees.  The Source and Computed option shows the entire tree
(including computed trees joined at the appropriate places) so it is
more suitable if you have many smaller computed trees.  Finally, the
Incremental display allows access to the entire tree that has been
computed so far.  
<P>
The tree displays can be saved as Postscript via the Tree menu.  You can
elect to save just the visible portion of the tree or the whole tree.
<A NAME="IDX73"></A>
<A NAME="IDX74"></A>
<P>
In any of the tree displays it is possible to select nodes with the left
button.  The abstract grammar production derived at that node will be
displayed in the transcript window and the input text extent of the node
will be highlighted in the input text window.
<P>
Also, the right button can be used on a symbol (rule name) to display a
menu listing the attributes (attributes and terminal values) of that
occurrence of the symbol (rule).  Each attribute or terminal has a pull
right menu with which you can indicate whether you want to see its value
(with optional stopping of execution) or ignore it (the default).  Using
this facility you can check that your attribution is working correctly.
Note that values will only be displayed when they are next calculated,
so you will need to run the program again after selecting some values
for display.
<A NAME="IDX75"></A>
<P>
Note: The current version of Noosa is not able to deal properly with
chain
<A NAME="IDX77"></A>
<A NAME="IDX76"></A>
attributes.  Chain attributes will show up in the attribute menu as a
pair of regular attributes with <CODE>_pre</CODE> and <CODE>_post</CODE> appended to
the attribute name.  It is possible to select these attributes for
display.  However, in the current system, not all will be displayed
because of limitations in the generated processor code.
<P>
Noosa has a simple mechanism for displaying the values of attributes in
the transcript window.  Values are displayed preceded by their type
name.  If a value can be browsed (or "opened") it will be underlined
and browsing is performed by clicking on the value with the left button.
<P>
Eli currently has support to allow the following types of value to be
browsed.
<P>
<DL COMPACT>
<A NAME="IDX78"></A>
<DT>Tree nodes (Node, NODEPTR)
<DD>Clicking on a tree node value causes your abstract tree display(s) (if
any) to highlight that node.  A NODEPTR value is a run-time pointer to a
tree node.  Clicking on one of these values will select the
corresponding node in a tree display if it is there.
<P>
<A NAME="IDX79"></A>
<DT>PTG nodes (PTGNode)
<DD>Opening a PTG node causes the system to run the function
<CODE>PTGOutFile</CODE> on the node and display the resulting output in the
transcript window.  Note that due to side-effects in PTG functions or
redirected output, the text displayed may not be same as the text
finally output by your processor.
<P>
<A NAME="IDX80"></A>
<DT>Environments (Environment)
<DD>Opening an environment produces in the transcript a list of the name-key
pairs in that environment.  If the environment is nested within another
environment then the parent environment is printed so that it can be
browsed as well.
<P>
<A NAME="IDX81"></A>
<DT>Bindings (Binding)
<DD>Opening a binding will produce the identifier that is bound (<CODE>IdnOf</CODE>),
the key to which it has been bound (<CODE>KeyOf</CODE>),
and the environment containing the binding (<CODE>EnvOf</CODE>).
<P>
<A NAME="IDX82"></A>
<DT>Definition table keys (DefTableKey)
<DD>Opening a definition table key will produce a list of the current
properties of that key and the values of those properties.
<P>
<A NAME="IDX83"></A>
<DT>OIL types and typesets (tOilType, tOilTypeSet)
<DD>These types are used for operator identification.  Opening an OIL
type shows the type name (a definition table key).  Opening an OIL
typeset shows the elements of the set and their associated costs.
<P>
<A NAME="IDX84"></A>
<DT>Tree parser nodes (TPNode)
<DD>Opening a tree parser node will produce the node name and a list of its
children.
</DL>
<P>
<A NAME="IDX85"></A>
<A NAME="IDX86"></A>
<A NAME="IDX87"></A>
<A NAME="IDX88"></A>
<H2><A NAME="SEC14" HREF="mon_toc.html#SEC14">Breakpoints and events</A></H2>
<P>
Noosa follows the progress of your program using
<A NAME="IDX89"></A>
<DFN>events</DFN>.  When a significant thing happens during execution the
program will generate an event to signal that fact to the monitoring
system.  Event instances have
<A NAME="IDX91"></A>
<A NAME="IDX90"></A>
<DFN>parameters</DFN> which allow them to provide arbitrary information to
the monitoring system.
<P>
Breakpoints in the Noosa system are conceptually similar to breakpoints
in source-level debuggers, but operate at the level of events rather
than source code locations, functions or variables.
They are implemented by attaching handlers to event types.
<P>
The Handlers command in the Windows menu creates a dialog window through
which you can enter handlers for the different types of events that your
program may produce during execution.  A list of relevant event types is
displayed and handlers can be entered, edited, deleted etc.  (See the
Help menu in the Handlers dialog for more information.)
<A NAME="IDX93"></A>
<A NAME="IDX92"></A>
Handlers can also be saved to files and autoloaded, see See  <A HREF="mon_1.html#SEC4">User Initialisation</A>.
<P>
Handlers are expressed using the
<A NAME="IDX95"></A>
<A NAME="IDX94"></A>
Tool Command Language (Tcl).  (A complete description of TCL is beyond
the scope of this manual.  See the Tcl online manual pages or any book
on Tcl/Tk for details.)  Handlers can contain arbitrary Tcl code and may
refer to the event parameters as Tcl variables.  To cause execution to
stop as the result of handler execution, have the handler call the Tcl
<CODE>n_break</CODE> command.
<P>
For example, the following handler causes execution to stop if the
string <CODE>printf</CODE> is stored into the string table.
This handler would be attached to the <CODE>string_stored</CODE> event.
<P>
<PRE>
if {$string == "printf"} {
    n_break
}
</PRE>
<A NAME="IDX96"></A>
<A NAME="IDX97"></A>
<P>
There is no requirement that a handler actually cause execution to stop.
It may just display information and allow execution to continue.  Within
a handler, the builtin Noosa command <CODE>n_say</CODE> may be used to display
information in the Noosa transcript window.  
<P>
For example, the following handler causes the lexeme of every token on
line three of the input to be displayed.  This handler would be attached
to the <CODE>token</CODE> event type thereby making the <CODE>linebeg</CODE> and
<CODE>lexeme</CODE> parameters available.
<P>
<PRE>
if {$linebeg == 3} {
    n_say "lexeme is $lexeme\n"
}
</PRE>
<P>
All Eli-generated programs prepared for monitoring automatically
generate a single event instance of type
<A NAME="IDX99"></A>
<A NAME="IDX98"></A>
<CODE>init</CODE> at the beginning of execution, and one of type 
<A NAME="IDX101"></A>
<A NAME="IDX100"></A>
<CODE>finit</CODE> at the end of execution.
This can be useful if you want to collect some information using handlers
during execution and display a summary at the end using a handler on
the <CODE>finit</CODE> event type.
<P>
<A NAME="IDX102"></A>
<A NAME="IDX103"></A>
<A NAME="IDX104"></A>
<A NAME="IDX105"></A>
<H2><A NAME="SEC15" HREF="mon_toc.html#SEC15">Frequency Profiles</A></H2>
<P>
Frequency profiles provide information about the frequency of
events generated by your program.  When execution stops, a summary of
events generated up to that point will be produced.  The summary
contains the name of each event type generated and the count of the
number of times events of that type were generated by a particular
component of the program.
<P>
Frequency profiles are enabled and disabled by the Frequency profile
checkbutton in the Profile menu.  By default they are disabled.  The
Zero frequencies command can be used to set all of the frequencies to
zero.  This can be useful if you only want to collect frequencies from a
particular point during the execution.
<P>
<A NAME="IDX106"></A>
<A NAME="IDX107"></A>
<A NAME="IDX108"></A>
<H2><A NAME="SEC16" HREF="mon_toc.html#SEC16">Time Profiles</A></H2>
<P>
Time profiles provide information about the CPU time spent in
components of your program.  For each component the CPU time in seconds
is given with the percentage of total CPU time due to that component.
<P>
Time profiles are enabled and disabled by the Time profile command in
the Profile menu.  By default they are disabled.  The Reset times
command can be used to set all of the times to zero.
<P>
Time profiles are obtained by generating an
<A NAME="IDX109"></A>
<CODE>enter</CODE> event each time execution enters the code for a component,
and a
<A NAME="IDX110"></A>
<CODE>leave</CODE> event when execution leaves again.  Consequently, time is
only allocated to components which have appropriate monitoring support.
Currently, the main components within Eli have this support, but not all
components do.  Also, due to the short running time of most
Eli-generated programs on test input, the times reported in a time
profile are likely to vary considerably from run to run due to the
granularity of the timing mechanisms.  Consequently, time profiles
should only be relied on when using large inputs or running time is
larger for some other reason.
<P>
<A NAME="IDX111"></A>
<H2><A NAME="SEC17" HREF="mon_toc.html#SEC17">Tracing Events</A></H2>
<P>
Sometimes it is useful to see the event stream generated by your
program.  The Event trace command in the Profile menu provides this
capability.  When tracing is enabled Noosa will display the event type
and parameters of every event generated by the program until it stops.
<P>
The Set event filter command allows subsets of events to be selected
using a regular expression.  A dialog box allows you to set a new
expression or clear an old one.  Executing the Set event filter command
will cause subsequent tracing to display an event only if the event
information matches the regular expression.  The default regular
expression is <CODE>.*</CODE> meaning all events are displayed.
<P>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_1.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_3.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="mon_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>
